On my site I use two themes, a stripped down custom theme for non-users (kpsuold) and bluemarine. My user has bluemarine selected as its theme. I've found that I'm unable to make changes to the blocks on kpsuold using the admin/block/list/kpsuold form. All changes are made to bluemarine instead. If I switch my theme to the kpsuold theme and try to edit the blocks on bluemarine, it changes kpsuold.
I inserted a few var_dump()s and noticed that, other than loading the theme, it acts exactly the same as when I view admin/block/list/bluemarine (i.e. '#action' => 'admin/block/list/bluemarine' instead of '#action' => 'admin/block/list/kpsuold'.
I'll do some more poking and try to roll up a patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | block.module_9.patch | 2.35 KB | drewish |
Comments
Comment #1
drewish commentedI've put together a patch that seems to fix the problem. I moved some code that initialized non-default form from
theme_block_admin_display()up toblock_admin_display()so it's called before the form is built.Globals freak me out so I tried to minimize the use in
block_admin_display(). It might make more sense to declare$theme_keyas a global rather than introducing the new$themevariable.Either way, I've verified that it:
* loads a theme's region list
* saves blocks for each theme
It would be nice if we could prevent the theme from sending out its stylesheet if its not the user's selected theme...
Comment #2
asimmonds commentedI think I fixed this bug in my formapi _execute conversion in http://drupal.org/node/35524. I could roll a patch against current HEAD just for this issue if needed.
Comment #3
drewish commentedHumm, I thought you'd gotten that committed already...
I grabbed the latest patch you had up but it doesn't work right. If no theme is provided it edits the user's theme instead of the system default. I'll upate your patch.
Comment #4
drewish commentedmy changes are now merged into asimmonds' patch.
Comment #5
(not verified) commented